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EXAMINER'S ANSWER 



This is in response to the appeal brief filed March 14, 2006, appealing from the Office action 
mailed November 1, 2005. 
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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

5,420,883 SWENSEN et al. 5-1995 

5,533,695 HEGGESTAD et al. 7-1996 
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5,620,155 



MICHALEK 



4-1997 



5,785,283 



EHRENBERGER et al. 



7-1998 



5,786,998 



NEESON et al. 



7-1998 



5,848,064 



COWAN 



12-1998 



5,978,718 



KULL 



11-1999 



David C. Coll, et al., "The Communications System Architecture of the North American 
Advanced Train Control System," August 1990. 

Hamid R. Sharif and Edward L. Furman, "Analytical Model for ATCS Inbound RF 
Channel Throughput," 1 99 1 . 

The above two non-patent documents were cited by the examiner in the Office action 
mailed 04/05/2004 as describing details of the communication interfaces within the Advanced 
Train Control System (ATCS), on which U.S. Patent No. 5,786,998 to Neeson et al. relies. See, 
e.g.,Neeson et al, col. 1, lines 63-66 and col 22, lines 55-59; (see also Non-final Rejection 
(04/05/2004) at p. 5.) 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claims 1-3, 7, 9, 10, and 15-19 are rejected under 35 U.S.C. 103(a) as being unpatentable 

over U.S. Patent No. 5,786,998 to Neeson et al. in view of U.S. Patent No. 5,533,695 to 

Heggestad et al. and U.S. Patent No. 5,978,718 to Kull. 

Claim 4 is rejected under 35 U.S.C. 103(a) as being unpatentable over Neeson, 

Heggestad, and Kull, as applied to claim 1 above, and further in view of U.S. Patent No. 

5,848,064 to Cowan. 
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Claims 20 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable over Neeson, 
Heggestad, and Kull, as applied to claim 1 above, and further in view of U.S. Patent No. 
5,420,883 to Swensen et al. 

Claims 46-49 are rejected under 35 U.S.C. 103(a) as being unpatentable over Neeson, 
Heggestad, and Kull, as applied to claim 1 above, and further in view of U.S. Patent No. 
5,785,283 to Ehrenberger et al. 

Claim 51 is rejected under 35 U.S.C. 103(a) as being unpatentable over Neeson, 
Heggestad, and Kull as applied to claim 1 above, and further in view of U.S. Patent No. 
5,620,155 to Michalek. 

(10) Response to Argument 

Claim 1, Second Paragraph (Appeal Brief at pp. 5-8) 

The second paragraph of Appellant's Claim 1 recites, 

determining from the data base the location of the train relative to the 
track structure and whether the train is within communication range of one of the 
remote base stations, the determining being made by using location information 
about the train, information about the track structure and location information 
about the multiple remote base stations from the data base stored on the computer 
onboard the train; 

See Claim 1 . 

Appellant's arguments in section 1(B)(1) for Claim 1, 2 nd paragraph (Appeal Brief 
at p. 5) 

A careful reading of the Office action, (see Final Rejection (1 1/01/2005) at pp. 4-5 9 ) 
shows that rather than failing to cite a disclosure in Neeson et al. that meets Appellant's "from a 
database" clause, the examiner conceded, in accordance with the factual analysis set forth in 
Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that Neeson et al. does not 
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expressly disclose the use of a data base. The Office action reflects that Neeson et ah discloses 
the remaining features the limitation in question, and relies upon the Kull reference as suggesting 
the use of an onboard database to determine locomotive location relative to track structures and 
remote base stations, {see Final Rejection (1 1/01/2005) at pp. 4-5.) 

Appellant's arguments in section 1(B)(2) for Claim 1, 2 nd paragraph (Appeal Brief 
at p. 5) 

With regard to Appellant's interpretation of the disclosure in col. 5, lines 16-32 of 
Neeson et al., the examiner asserts that the half-duplex nature of the MCP restricts the MCP in 
that it cannot simultaneously receive and transmit messages (as expressly disclosed in the above- 
cited section of Neeson et al.). In response, the MCP had been designed so that it would not 
remain stuck in a transmit-only mode, repeatedly attempting to send data packets while the 
locomotive is out of range. This was done (as disclosed by Neeson et al.) to prevent a possible 
situation in which the continuously-transmitting MCP could miss important emergency 
information from the dispatcher. The cited section of the Neeson et al. reference does not, as 
Appellant suggests, disclose that the ground network must initiate communication. Determining 
that a base station is out of range is not the same thing as waiting for a base station to initiate 
communication. Rather, the system of Neeson et al. is an event-driven system that responds to 
such events as the MCP losing ground contact or exiting the coverage area (corresponding to an 
ALERTS_EVENT value of LOST_CONTACT) and the MCP regaining ground contact or 
entering coverage (corresponding to an ALERTS_EVENT value of REG CONTACT). Upon a 
LOST_CONTACT event, the system state (ALERT_STATE) changes to one of OOCJDLE, 
OOC_CHG_PEND, and OOC_RPT_OUTSTANDING (see Fig. 4), and the appropriate state- 
dependent procedures (beginning with "S_") are called (see col. 14, line 10, through col. 15, line 
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34). Upon a REG_CONTACT event, the system state changes to one of CHECKTABLE, 
RPT_OUT, and CHG_PEND_RPT_OUT (see Fig. 4). 

Appellant's arguments in section 1(B)(3) of the Appeal Brief for Claim 1, 2 nd 
paragraph (Appeal Brief at pp. 5-6) 

The examiner respectfully submits that if the train and a remote base station are in 

communication, they are, logically, also in communication range . Thus, even assuming, 
arguendo, that Appellant is correct in that Neeson et al. only discloses determining onboard 
whether the train and a remote base station are in communication, this is also a determination 
that the train and the remote base station are in communication range. 

Appellant's arguments in section 11(B) of the Appeal Brief for Claim 1, 2 nd 
paragraph (Appeal Brief at p. 6) 

The examiner respectfully submits that it is precisely because the OBC in Heggestad et 

al. is continuously provided with location information (from trackside transponders) that the train 
knows its exact location. Contrary to Appellant's assertion, this does not make it unnecessary 
for the OBC to establish communication. Rather, the system of Heggestad et al. must establish 
communication in order to receive authority and profile data. See, e.g., Heggestad at col. 7, lines 
6-20, and col. 9, line 15, through col. 10, line 25. 

Appellant's arguments in section lll(B) of the Appeal Brief for Claim 1, 2 nd 
paragraph (Appeal Brief at pp. 6-7) 

Again, the examiner asserts that a careful reading of the Office action, {see Final 

Rejection (1 1/01/2005) at pp. 4-5,) shows that rather than failing to cite a disclosure in Neeson et 
al. that meets Appellant's "from a database" clause, the examiner conceded, in accordance with 
the factual analysis set forth in Graham v. John Deere Co., that Neeson et al. does not expressly 
disclose the use of a data base. The Office action reflects that Neeson et al. discloses the 
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remaining features the limitation in question, and relies upon the Kull reference as suggesting the 
use of an onboard database to determine locomotive location relative to track structures and 
remote base stations, {see Final Rejection (1 1/01/2005) at pp. 4-5.) 

Appellant's arguments in section IV(B) of the Appeal Brief for Claim 1, 2 nd 
paragraph (Appeal Brief at p. 7) 

Neeson et al. describes a system that relies extensively on the ATCS standards. See, e.g., 

Neeson at col. 22, lines 55-59 ("[T]he application of the present invention is designed to 'piggy 
back 5 on the already existing ABNS and ATCS systems . . . ."); Id. at col. 10, lines 55-57 ("[T]he 
ALERTS application is designed to read Health Reports which conform to the latest ATCS 
standards.")- Heggestad et al., as cited by the examiner, very clearly describes one disadvantage 
of the ATCS systems. Heggestad at col. 2, lines 21-29 ("Both Auer and the ATCS systems, 
however, require duplicating, in a central office computer, most or all of the vital logic 
performed at interlockings. This creates the potential for a discrepancy in timing, if not in 
content, between authorities granted from the central office logic versus those displayed by the 
wayside signals . . . ."). Heggestad proposes a solution which, among other things, uses fixed 
profile data and dynamic authority data derived from wayside vital logic and using the on-board 
computer to merge the fixed and dynamic data. E.g., Heggestad at col. 3, lines 29-40. 
Therefore, the examiner submits that there is ample motivation to combine the teachings of 
Heggestad with the disclosure of Neeson, and Appellant's arguments otherwise are unfounded. 
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Appellant's arguments in section V(B) of the Appeal Brief for Claim 1, 2 nd 
paragraph (Appeal Brief at pp. 7-8) 

The examiner submits that Kull does not merely teach having information in a database, 

but rather teaches using the information in a database to determine the location of the train 

relative to the track structure. For example, of Kull discloses: 

According to instructions contained within its programming code, the computer 
240 uses the enumerated signals along with an in comparison to the 
aforementioned data to determine not only the position that the train occupies on 
the railway track but also the whereabouts of the upcoming wayside signal device 
relative to the position of the train. Specifically, the computer 240 determines 
where the train is located in relation to the track route location data stored in the 
onboard database. 

Kull at col. 9, lines 19-27. 

The system of Kull provides the capability to determine whether a locomotive is within 

communication range {e.g., visual communication) of one of these wayside signal devices in 

order to facilitate proper operation of the locomotive. E.g., Id at col. 1, lines 14-44. Neeson et 

al. likewise disclose a railway communications system in which locomotives are controlled 

through operational status messages. E.g., Neeson at col. 8, lines 1 1-24. Furthermore, Kull 

provides the advantage of additional warning capabilities based on visual aspects of wayside 

signal devices in situations where a cab signal is unavailable. E.g., Kull at col. 5, lines 1-17. 

Claim 1, Third Paragraph (Appeal Brief at pp. 8-11) 

The third paragraph of Appellant's Claim 1 recites, 

establishing from onboard the train a wireless communication with one of 
the multiple remote base stations determined to be within communication range; 

See Claim 1 (emphasis added). 
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It should be noted that Appellant attempted to improperly amend claim 1 in the reply 

filed 01/13/2004, necessitating a rejection under 35 U.S.C. § 1 12, first paragraph, for failing to 

comply with the written description requirement: 

Applicant's amendments to claims 1 and 10, replacing "establishing" with 
"initiating"/"initiating from" do not appear to be directly supported by the 
originally-filed specification. In particular, the relevant portions of the 
specification (p. 8, line 19, through p. 9, line 12) discuss establishing wireless 
communication but do not discuss initiating from onboard the locomotive such 
wireless communication apart from the general establishment of such 
communication. 

(Non-Final Rejection (04/05/2005) at pp. 5-6 (emphasis in original).) Appellant responded by 
amending the claims accordingly: 

Claim 1 has been amended to remove the objectionable language of "initiating." 
Instead, it now requires "attempting and establishing" from onboard the wireless 
communication. This is specifically supported in the specification on page 8, 
lines 24-29. 

(Remarks (08/31/2004) at p. 2.) Thus, the examiner emphasizes that claim 1 requires (as written, 
and in view of the enabling specification) establishing from onboard wireless communication 
and not initiating from onboard such communication. 

Appellant's arguments in section 1(B)(1) of the Appeal Brief for Claim 1, 3 rd 
paragraph (Appeal Brief at p. 8) 

As stated above, Appellant's claims do not require initiating communication. Further, 

Neeson et al. describes establishing communication as discussed throughout this Answer. See, 
e.g., Neeson at col. 3, lines 61-66. 

Appellant's arguments in section 1(B)(2) of the Appeal Brief for Claim 1, 3 rd 
paragraph (Appeal Brief at pp. 8-9) 

The examiner submits that Appellant is mischaracterizing the disclosure of Neeson et al. 

Appellant's cited section of Neeson et al. (column 7, lines 29-47) merely describes that the 
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overall system disclosed by Neeson et al. comprises two distinct networks: (1) the ground 
network, which connects the base stations and the front end processor, and (2) the radio 
frequency network, which connects the base stations and the field units. Because the base 
stations are part of both networks, they provide the interface between the two, i.e., there are 
ground network connections between the base stations and the front end processor, and there are 
radio frequency "connections" between the base stations and the field units. This in no way 
supports Appellant's contention that the ground network or remote stations are in control of 
communications with the locomotive. Further, Neeson et al. discloses the field unit (locomotive) 
remaining in radio contact range of the nearest base station as it moves along the track; "Passing 
off infers that as a new base station comes within range, radio communication is handled by the 
new base station that is determined to be within range. See Neeson at col. 7, lines 33-47. 
Executing the handoff requires that the locomotive computer establish onboard wireless 
communication with the new base station in order to remain in contact. See Id. 

Appellant's arguments in section 1(B)(3) of the Appeal Brief for Claim 1, 3 rd 
paragraph (Appeal Brief at p. 9) 

Appellant's cited section of Neeson et al. (column 7, lines 29-47) merely describes that 

the overall system disclosed by Neeson et al. comprises two distinct networks: (1) the ground 
network, which connects the base stations and the front end processor, and (2) the radio 
frequency network, which connects the base stations and the field units. Because the base 
stations are part of both networks, they provide the interface between the two, i.e., there are 
ground network connections between the base stations and the front end processor, and there are 
radio frequency "connections" between the base stations and the field units. This in no way 
supports Appellant's contention that the ground network or remote stations are in control of 
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communications with the locomotive. Further, the cited disclosure, . .in ABNS, 

communications with locomotives is initiated through the base stations which are in contact with 

mobile communications packages (MCP) on-board the locomotives," see Neeson at col. 2, lines 

5-7, merely states that communication is initiated through the base stations, and not initiated 

by the base stations, as Appellant has apparently interpreted the passage. The implication of this 

disclosure is that the system does not communicate directly with the locomotives, but rather uses 

the base stations as intermediate nodes. This interpretation is further supported by the following 

disclosure from Neeson et al.: 

The base networking system enables communications contact with the on-board 
computer 14 on a locomotive via the mobile communications package 12. Speed and 
control information may thus be sent from the locomotive 38 through the MCP 12 
through the base stations 52 and 54 to the front end processor 46 where the 
information is stored in a particular address allocated to the particular locomotive 38. 
Likewise, traffic control information and the like may be sent from the dispatcher 32 
through the front end processor 46 to the base stations 52 and 54 and from there to the 
mobile communications package 12 on board the locomotive 38 to coordinate 
locomotive movement throughout the railroad system. 

Neeson at col. 8, lines 1 1-23 (emphasis added). 

Appellant's arguments in section 11(B)(1) of the Appeal Brief for Claim 1, 3 rd 
paragraph (Appeal Brief at pp. 10-11) 

Appellant's bold accusation of hindsight reasoning is addressed below in the context of 

the specific factual assertions that Appellant has challenged. (See the three sections that 
immediately follow.) 

Appellant's arguments in section 11(B)(2) of the Appeal Brief for Claim 1, 3 rd 
paragraph (Appeal Brief at p. 11) 

Contrary to Appellant's assertion, the Office action clearly cites col. 5, lines 23-27 of 

Neeson et al. as describing a pair of frequencies being used for communications between base 
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stations and the locomotive MCP, one frequency being used for transmissions from the base 
station to the locomotive (incoming messages), and another is used for transmissions from the 
locomotive to the base station (outgoing messages). (See Final Rejection (1 1/01/2005) at p. 3.) 

Appellant's arguments in section 11(B)(3) of the Appeal Brief for Claim 1, 3 rd 
paragraph (Appeal Brief at p. 11) 

It should be noted that the factual assertions at issue were first made in the Office action 

mailed 04/05/2004 in response to Appellant's arguments in the reply filed 01/13/2004. In 

particular, the examiner maintained (and still maintains) that the two-frequency communication 

system of Neeson et al. requires the locomotive to initiate all communication at frequency used 

for outgoing messages because the remote bases stations do not transmit at that frequency and 

therefore cannot initiate such communication. See Neeson at col. 5, lines 23-27. The examiner 

then stated alternative grounds for maintaining the rejection, specifically, noting: 

[E]ven if Applicant's characterization of the Neeson et al. system were correct, 
Neeson et al. still meets the limitations recited in the claims. If a base station 
initiates communication with a locomotive MCP, then the locomotive must 
receive, process, and respond to such initiation. In other words, the initial data 
packet(s) transmitted by the base station must be understood by the MCP as being 
from a base station within range (otherwise such communication would not be 
possible/successful), and further, the MCP must acknowledge such initiating with 
an appropriate response, i.e., the MCP must carry out its own communication 
initiating procedures to enable communication to take place with the base station. 
Without providing this basic functionality, the prescribed communication system 
would not be able to exchange data between the base station and the locomotive 
MCP. Communication must be established on both ends for the system to 
function. 

(Non-Final Rejection (05/04/2004) at pp. 4-5.) In the same Office action, the examiner cited the 
Coll and Sharif references, (see supra Sec. 8,) explaining that these references describing details 
of the communication interfaces within the Advanced Train Control System (ATCS), on which 
U.S. Patent No. 5,786,998 to Neeson et al. relies. See, e.g., Neeson et ai 9 col. 1, lines 63-66 and 
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col. 22, lines 55-59; (see also Non-final Rejection (04/05/2004) at p. 5.) . The Sharif reference 
describes the inherent functions that implement the inbound RF channel (the channel from the 
locomotive to the base station) of the ATCS system used by Neeson et al. See Neeson et al, col. 
1, lines 63-66 and col 22, lines 55-59; Sharif at pp. 885-886 (describing the format of the 
communication packets, the use of the Forward Error Correction protocol, and the channel 
access protocol — the locomotive waits for the channel to be idle before initiating communication 
with the base station). 

Appellant's arguments in section 11(B)(4) of the Appeal Brief for Claim 1, 3 rd 
paragraph (Appeal Brief at p. 11) 

The examiner respectfully disagrees with Appellant's characterization of the Neeson et 

al reference. First, the cited disclosure, "...in ABNS, communications with locomotives is 
initiated through the base stations which are in contact with mobile communications packages 
(MCP) on-board the locomotives," see Neeson at col. 2, lines 5-7, merely states that 
communication is initiated through the base stations, and not initiated by the base stations, as 
Appellant has apparently interpreted the passage. The implication of this disclosure is that the 
system does not communicate directly with the locomotives, but rather uses the base stations as 
intermediate nodes. This interpretation is further supported by the following disclosure from 
Neeson et al.: 

The base networking system enables communications contact with the on-board 
computer 14 on a locomotive via the mobile communications package 12. Speed and 
control information may thus be sent from the locomotive 38 through the MCP 12 
through the base stations 52 and 54 to the front end processor 46 where the 
information is stored in a particular address allocated to the particular locomotive 38. 
Likewise, traffic control information and the like may be sent from the dispatcher 32 
through the front end processor 46 to the base stations 52 and 54 and from there to the 
mobile communications package 12 on board the locomotive 38 to coordinate 
locomotive movement throughout the railroad system. 
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Neeson at col. 8, lines 1 1-23 (emphasis added). The examiner fully agrees with Appellant that it 
is improper to "pick and choose from any one reference only so much of it as will support a 
given position, to the exclusion of other parts necessary to the full appreciation of what such 
reference suggests to one of ordinary skill in the art." (Appeal Brief at p. 11 .) However, the 
examiner does not agree that it is the Office that failed to read the reference as a whole. 

Claim 4 (Appeal Brief at p. 11) 

Appellant has incorporated the arguments with respect to claim 1 into the argument for 
claim 4. Accordingly, the rejection of claim 4 should be affirmed for the reasons given above 
with respect to claim 1 . 

Claims 20 and 21 (Appeal Brief at p. 12) 

Appellant has incorporated the arguments with respect to claim 1 into the argument for 
claims 20 and 21. Accordingly, the rejection of claims 20 and 21 should be affirmed for the 
reasons given above with respect to claim 1 . 

Claim 51 (Appeal Brief at p. 12) 

Appellant has incorporated the arguments with respect to claim 1 into the argument for 
claim 51. Accordingly, the rejection of claim 51 should be affirmed for the reasons given above 
with respect to claim 1 . 

Claims 46-49 (Appeal Brief at pp. 12-13) 

The system of Ehrenberger et al. is direct to communications systems in the railway 
industry, and more particularly, to a system and method for communicating operational status 
information, such as a defect sensed by a wayside device, for display in the locomotive cab. 
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Ehrenberger at col. 1, lines 8-13. Ehrenberger et al. discloses as prior art the transmission of 
track data to control centers and locomotives. Id. at col. 1, lines 15-47. Ehrenberger et al. 
further recognizes a potential problem with locomotive communications systems where a 
message regarding a defect may not be responded to in a timely manner, possibly resulting in 
derailment of the locomotive. Id. Ehrenberger et al. addresses this problem by advantageously 
displaying track information onboard the train. Id. at col. 3, lines 9-21 . Neeson et al. likewise 
disclose a railway communications system in which locomotives are controlled through 
operational status messages. E.g., Neeson at col. 8, lines 1 1-24. Accordingly, the examiner 
maintains that the advantageous improvements to the railway communications system as taught 
by Ehrenberger et al. would be obvious to combine with the railway communications system of 
Neeson et al., which lacks these features, thus improving the awareness of train operators of 
potential hazards. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 

(12) Text of the Final Rejection 

Claims 1-3, 7, 9, 10, and 15-19 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over U.S. Patent No. 5,786,998 to Neeson et al. in view of 
U.S. Patent No. 5,533,695 to Heggestad et al. and U.S. Patent No. 5,978,718 to 
Kull. 

As per claim 1, Neeson et al. discloses collecting event recorder data, train 
performance data and track data from onboard in files on the on-board computer 
(see column 1, line 51 through column 2, line 4; and column 8, lines 1 1-24); 
determining onboard if a remote station is within communication range (see 
column 5, lines 16-32; and column 7, line 63 through column 8, line 3); and 
initiating from onboard wireless communication between an on-board computer 
(field unit) and a remote station (base station; see column 7, lines 29-47). Neeson 
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et al discloses a pair of frequencies being used for communications between base 
stations and the locomotive MCP. One frequency is used for transmissions from 
the base station to the locomotive, and another is used for transmissions from the 
locomotive to the base station (see col. 5, lines 23-27). The locomotive must 
initiate communication on the base station's receiving frequency because the base 
station does not transmit data at this frequency and therefore, cannot initiate such 
communication. Further, if a base station were to initiate communication with a 
locomotive MCP, then the locomotive must receive, process, and respond to such 
initiation. In other words, the initial data packet(s) transmitted by the base station 
must be understood by the MCP as being from a base station within range 
(otherwise such communication would not be possible/successful), and further, 
the MCP must acknowledge such initiating with an appropriate response, i.e., the 
MCP must carry out its own communication initiating procedures to enable 
communication to take place with the base station. Without providing this basic 
functionality, the prescribed communication system would not be able to 
exchange data between the base station and the locomotive MCP. 
Communication must be established on both ends for the system to function. 
Neeson et al further disclose determining onboard which of the files are new 
since last transmission, and transferring the new files to the remote station (see 
column 5, lines 1-15). 

Neeson et al fails to explicitly disclose determining onboard the location 
of the train and the location of the next remote station using location information 
about the train and the remote stations stored on the computer onboard the train. 
However, Heggestad et al teaches an incremental train control system in which 
multiple base stations (wayside interface units and wayside control units) are 
located at various intervals along a railroad track (see, for example, col. 4, line 66, 
through col. 5, line 13 of Heggestad et al). The onboard computer of a 
locomotive communicates with the wayside equipment via a radio link (see, for 
example, col. 5, lines 33-35 of Heggestad et al). Each wayside unit is 
responsible for the control of trains within a local area covered by each unit (see, 
for example, col. 6, lines 50-56 of Heggestad et al). The onboard computer, 
already knowing the exact location of the train, transmits a request for authority to 
the appropriate nearby wayside unit (see, for example, col. 7, lines 6-20 of 
Heggestad et al; see also col. 9, line 15, through col. 10, line 25). Heggestad et 
al further teaches the location of the train and the location of the nearby wayside 
unit being stored in the computer onboard the train (see, for example, see, for 
example, col. 7, lines 6-20 of Heggestad et al; see also col. 9, line 15, through 
col. 10, line 25). Therefore, it would have been obvious to one of ordinary skill in 
the computer art at the time the invention was made to modify the system of 
Neeson et al to include such determining the location of the train and the location 
of the appropriate remote station as per the teachings of Heggestad et al On 
would be motivated to do so to as part of using a known means of overcoming 
known deficiencies in the ATCS (Advanced Train Control System) on which 
Neeson et al is based (see, for example, col. 2, lines 9-29 of Heggestad et al). 
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Neeson et al further fails to expressly disclose the computer having a 
database including track structure information and location information about 
multiple remote base stations and the determining the location of the train using 
the database information. However, Kull teaches such a database and its use in 
determining location relative to track structures and remote base stations (see, for 
example, col. 8, lines 27-35). Therefore, it would have been obvious to one of 
ordinary skill in the computer art at the time the invention was made to further 
modify the system of Neeson et al to include such a database and relative 
location determination as per the teachings of Kull. One would be motivated to 
do so to provide additional warning capabilities to a train operator. 

As per claims 2 and 3, Neeson et al discloses determining whether a 
remote station has updates to be transferred and transferring the updates, 
including software updates (configuration changes) to the on-board computer (see 
column 19, lines 49-67). Therefore, for reasons stated above, such claims also 
would have been obvious. 

As per claim 7, Neeson et al further discloses resuming file transfers 
during subsequent communication sessions after an interruption of wireless 
communication (see column 14, line 10 through column 15, line 34). Therefore, 
for reasons stated above, such a claim also would have been obvious. 

As per claim 9, Neeson et al further discloses files including data from 
plural event recorders (intelligent devices) that transfer data to the on-board 
computer (processing device; see column 4, lines 44-57). Therefore, for reasons 
stated above, such a claim also would have been obvious. 

As per claim 10, Neeson et al further discloses the plural event recorders 
each connected to a respective on-board computer (intelligent devices have 
computer processing - "receive and understand" capabilities; see column 2, lines 
5-27), initiating wireless communication between the on-board computers 
(intelligent devices) and the remote station (intelligent devices communicate to 
the base stations via the processing device), and transferring event recorder data 
from each of the on-board computers to the remote station (see column 4, line 33 
through column 5, line 15). Therefore, for reasons stated above, such a claim also 
would have been obvious. 

As per claim 15, Neeson et al further discloses establishing 
communication between a remote station (base station) and a home base station 
(front end processor), and determining what files need to be transferred and 
transferring the files (see column 8, lines 11-18 and lines 40-44). Therefore, for 
reasons stated above, such a claim also would have been obvious. 

As per claim 16, Neeson et al further discloses transferring operational 
data for the onboard computer (traffic control information; see column 8, lines 18- 
24) from the home base station (front end processor) to the remote station (base 
station). Therefore, for reasons stated above, such a claim also would have been 
obvious. 

As per claims 17 and 18, Neeson et al further discloses transferring 
operation information of the remote station, including locomotives contacted 
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(locomotive ID) from the remote station (base station) to the home base station 
(front end processor; see column 12, lines 50-67). Therefore, for reasons stated 
above, such claims also would have been obvious. 

As per claim 19, Neeson et al further discloses establishing 
communication between the remote station (base station) and the home base 
station (front end processor) when requested by a user or according to a schedule 
(see column 10, lines 19-24). Therefore, for reasons stated above, such a claim 
also would have been obvious. 

Claim 4 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Neeson, Heggestad, and KuU y as applied to claim 1 above, and further in view 
of U.S. Patent No. 5,848,064 to Cowan. 

As per claim 4, Neeson teaches transferring updates to the on-board 
computer (see column 19, lines 49-67) but fails to teach comparing the version of 
a file in the on-board computer to the version of a file in the remote station to 
affect what is transferred. However, Cowan teaches changing the operating 
software of mobile terminals by detecting a change in a software version identifier 
in a remote station (host computer) and transferring the change (new version) 
resulting from the comparison (see column 6, lines 41-51). Therefore, it would 
have been obvious to one having ordinary skill in the computer art at the time the 
invention was made to modify the software updating method of Neeson to include 
the version comparison of Cowan. One would be motivated to do so to ensure 
that on-board computer's software is kept up-to-date. 

Claims 20 and 21 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Neeson, Heggestad, and Kiill, as applied to claim 1 above, 
and further in view of U.S. Patent No. 5,420,883 to Swensen et al. 

As per claims 20 and 21, Neeson teaches transferring files between an on- 
board computer and a remote station (base station; see column 8, lines 1 1-24) but 
fails to teach transferring files between remote stations. However, Swensen 
teaches a hierarchical scheme in which remote stations (trackside radios) 
retransmit received messages to other, different level, remote stations within a 
subnet (see column 5, line 64 through column 6, line 29 and Figure 12). 
Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to modify the Neeson method to include the 
retransmitting scheme of Swensen. One would be motivated to do so to allow for 
contacting a train or remote station where a direct link is not possible. 

Claims 46-49 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Neeson, Heggestad, and Kull, as applied to claim 1 above, 
and further in view of U.S. Patent No. 5,785,283 to Ehrenberger et al. 

As per claims 46 and 47, Neeson teaches transferring data from a remote 
station to an on-board computer and from an on-board computer to a remote 
station (base station; see column 8, lines 1 1-24) but fails to teach transferring 
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track data or displaying track data on the train. However, Ehrenberger teaches 
transferring track data (wayside defects) from a remote station (wayside system) 
to an on-board computer (see Figure 1) and displaying the track data on the train 
(see column 3, lines 9 through 21). Therefore, it would have been obvious to one 
having ordinary skill in the art at the time the invention was made to modify the 
Neeson method to include transferring track data to the on-board computer and 
displaying the track data as taught by Ehrenberger and subsequently transferring 
the track data to another remote station. One would be motivated to do so to keep 
the train operator informed of potential hazards in the area and to disseminate the 
information to other train operators in the system. 

As per claim 48, in addition to the teachings applied above, Ehrenberger 
further suggests other types of track data, including status of a highway crossing 
analyzer (see column 6, lines 52-59). Therefore, it would have been obvious to 
one having ordinary skill in the art at the time the invention was made to further 
modify the Neeson method to include track information such as crossing gate 
position or crossing occupancy status as per the suggestion of Ehrenberger. One 
would be motivated to do so to communicate a potential highway crossing hazard 
to the locomotive operator in advance of the train approaching the highway 
crossing. 

As per claim 49, in addition to the teachings applied above, it would have been 
furthermore obvious to include correlating train performance data with track data, 
e.g. making a change in speed in response to a detected potential hazard. 

Claim 51 is rejected under 35 U.S.C. 103(a) as being unpatentable 
over Neeson, Heggestad, and Kull as applied to claim 1 above, and further in 
view of U.S. Patent No. 5,620,155 to Michalek. 

As per claim 51, in addition to the disclosure and teachings applied above, 
Neeson fails to expressly disclose the use of GPS to determine the location of the 
train. However, Michalek teaches such a use of GPS to determine the location of 
a train (see, for example, cols. 6 and 8). Therefore, it would have been obvious to 
one of ordinary skill in the computer art at the time the invention was made to 
further modify the Neeson method to include such use of GPS as per the teachings 
of Michalek. One would be motivated to do so to more accurately determine the 
location of trains (to within several yards). 
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EVIDENCE APPENDIX 

David C. Coll, et al., "The Communications System Architecture of the North American 
Advanced Train Control System," August 1990 (12 pages). 

Hamid R. Sharif and Edward L. Furman, "Analytical Model for ATCS Inbound RF 
Channel Throughput," 1991 (8 pages). 

Again, the above two non-patent documents were cited by the examiner in the Office 
action mailed 04/05/2004 as describing details of the communication interfaces within the 
Advanced Train Control System (ATCS), on which U.S. Patent No. 5,786,998 to Neeson et al. 
relies. See, e.g., Neeson et al, col. 1, lines 63-66 and col. 22, lines 55-59; {see also Non-final 
Rejection (04/05/2004) at p. 5; supra Section 8.) 
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The Communications System Architecture of the 
North American Advanced Train Control 

System 
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Abstract— Tit Advanced Train Control System (ATCS) CoramunJ. 
caltons System, which provide* for ibc Information flow la the North 
American ATCS, If pretested hi the context of the overall ATCS plan. 
The major components and basic operation of ATCS are described. 
The featum and functions of the nodes En the communication system, 
and (heir connect] rlty, are defined. The communications system b based 
oo (he OS I model; and the protocols used art described with particular 
emphasis oo the radio data link. Special features of the communications 
system, Including a description of how vehicles are tracked, Is Included. 

1. Introduction 

A. Definition and Objectives of the Advanced Train Con- 
trol System 

TN 1984, the American Association of Railroads and the 
Jjlailways Association of Canada founded the Advanced 
Train Control Systems (ATCS) Project. The purpose of the 
project was to modernize North American train movement 
control systems through a cooperative effort of railroads and 
equipment vendors, with the objective of establishing a unified 
set of standards for both procedures and equipment; leading to 
more economical, efficient and safer train movement in North 
America. 

The ATCS Project has been a privately funded project of 
the two railroad associations that has involved railroad per- 
sonnel, systems engineers, and potential equipment suppliers 
in a public open-forum process. It has met its objectives with 
the definition of a systems architecture that accommodates the 
flow of all necessary command and control information and 
with the formulation of open specifications for the components 
of the system. 

The specifications define the performance and interface re- 
quirements for ATCS hardware and software. ATCS specifica- 
tions ensure inter -operability, compatibility, safety, reliability, 
and functionality of components. They focus on form, fit, and 
function. They are not intended to be design or manufacturing 
specifications. They are designed to document the stated re- 
quirements of railroad operational and technical authorities 
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and to influence the design of new, compatible equipment 
without limiting the internal design approaches of individ- 
ual suppliers. Equipment suppliers are encouraged to produce 
high performance, low maintenance, and high reliability, 
equipment. They are free to accomplish these objectives and 
satisfy the requirements of the specifications by means of de- 
sign techniques and technology which they consider to be cost 
effective and appropriate. Suppliers and railroads purchasing 
hardware or software are responsible for ensuring that equip- 
ment and its applications satisfy regulatory and safety require- 
ments. 

The ATCS, as it has been defined, provides a continent- 
wide system of train control based on standardized equipment 
for the first time. Any vehicle outfitted with equipment that 
satisfies ATCS specifications may be controlled by any appro- 
priately equipped railroad, allowing railways to interact eco- 
nomically and safely, even across the Canada-U.S. border. 
While implementation of ATCS will represent a massive in- 
vestment in new equipment, the common specifications mean 
that the equipment will be available from many vendors who 
will manufacture to ATCS specifications— providing the rail- 
roads with the opportunity to realize significant economies of 
scale in the implementation. 

B. Basic Train Movements and Control 

The purpose of the ATCS is to move trains— safely, effi- 
ciently, and economically. 

Train movement within the ATCS is based on separation of 
trains through the principle of exclusive occupancy. This is 
a computer-aided block system in which the access of trains 
and track forces to any section of track, or block, is strictly 
controlled by "authorities" issued by a dispatcher. Trains are 
controlled by "movement authorities," while work crews and 
associated track vehicles are controlled through "track occu- 
pancy permits." A movement authority authorizes movement 
in one direction on a specified track to a specified point within 
known limits. No train or track force may move into or within 
a block without an authority, nor operate beyond a point to 
which they have been granted an authority. Where necessary, 
violation of the limits of movement authorities are enforced 
in ATCS through automatic brake application. 

The ATCS is designed to provide the information, commu- 
nications, and control required to automate and enhance this 
system of train control. 
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Fig. 1. ATCS system uchitecture— levels of information processing. 



C. Components of the Overall System 

The ATCS system architecture is based on an established 
model of information flow. This flow is shown in Fig. 1, in 
which six levels of information processing are illustrated: the 
continental level, the railroad level, the regional level, the 
dispatch level, and the wayside/mobile level. 

The major subsystems in ATCS are: the computer-aided 
Dispatch System; the Communications System; Locomo- 
tive Equipment; Track Forces Equipment; and Wayside 
Equipment, 

J) The Dispatch System: The dispatch system is respon- 
sible for planning the movement of trains; controlling the ex- 
ecution of the general movement plan; monitoring the status 
of each movement; and reporting operational data to the ap- 
propriate ancillary systems. 

The key elements of the dispatch system are dispatching 
consoles; the management system, which performs nonvital 
functions and plans daily train movements, plans track occu- 
pancies and track work, resolves train conflicts, and manages 
pacing; the safety system, which performs ail vital functions 
and analyzes movement authority requests, issues authorities, 
issues and releases track occupancy and track work permits, 
issues track condition notices, tracks train movements and 
work gangs and track occupancies, controls routing, handles 
ATCS messages, and maintains system lime; the communi- 
cations system interfaces; and the corporate management 
information systems interface. The dispatch system includes 
dispatch control logic applications software and data bases de- 
scribing such information as route configurations, train loca- 
tions, and outstanding authorities (train movement authoriza- 
tions). 

2) The Communications System: The communications 
system consists of u network of nodes and links to pro- 
vide communications between the dispatcher and locomotives, 
track forces, and wayside devices as described in Section II. 

3) Locomotive Equipment: The locomotive equipment 
comprises a data radio and communications package, an on- 
board computer, locomotive display, brake and throttle con- 
trols, odometers, and a transponder interrogator. 



Transponders, which are buried in the roadbed, provide 
coded information to interrogators mounted on the underside 
of locomotives. The interrogator radiates a radio signal which 
is inductively coupled to the transponder, powering it and 
enabling it to transmit its coded identification information back 
to the interrogator. The interrogator transmits energy at 200 
kHz and the data are transmitted by the transponder at 27 
MHz. 

The transponders are packaged so as to be impervious to 
moisture, insects, oil, grease, fuel, common corrosives, and 
ultraviolet radiation. They must be less than 18.5 in x 8 
in y 1.5 in in size and have an operating life of 15 a. They 
may be mounted between the rails or buried in the ballast. 
They are designed to work through up to 5 in of salt water or 
2 in of salt mud. 

Transponder data arc coded in a 64-b message frame, com- 
prising a synchronizing header (7 b), transponder type (4 b), 
and railroad identification (36 b), followed by a 17-h cyclic re- 
dundancy check in accordance with the D1GITRAC transpon- 
der specifications provided by Dynamic Sciences, Inc. The 
transponder transmits its message as long as it is receiving 
energizing radiation from an interrogator using differentia] 
phase shift keying of a 50-kHz data subcarrier whose am- 
plitude modulates a carrier at 27.255 MHz. 

The system is designed to provide a minimum of eight 
complete data frames to an interrogator when it is crossing 
a transponder from cither direction at speeds up to 130 mi/h. 
At the same time, the system is designed to avoid energizing 
transponders on parallel tracks within 12.5 ft. 

The locomotive on-board computer (OBC) executes a num- 
ber of functions that include movement authority enforcement 
and management; management of data bases describing track 
segments, interlocks, sidings, train characteristics, the loco- 
motive consist (i.e., its make-up), the car consist, ATCS ter- 
ritory levels, parallel lines, transponders, wayside devices, 
mileposis, communications coverage, grade crossings, high- 
way crossings, dispatcher change points, track conditions, and 
track work protection; location systems management; emer- 
gency management; wayside device interaction management; 
test management; message routing; pacing management; train 
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handling management; and irain crew and track force interac- 
tion management. 

4) Track forces: Track forces are maintenance and con- 
struction crews and other nonlocomotive entities occupying 
the track. They are able to communicate with dispatchers and 
ATCS data bases through a track forces data terminal con- 
sisting of an RF antenna, an ATCS mobile communications 
package and an ATCS auxiliary terminal. 

5) Wayside Devices: The ATCS field system consists of 
wayside interface units (WIU), controllable and noncontrol- 
lable devices. The WIU provides an interface between exist- 
ing field devices and the ATCS Communications System via 
Mobile Communication Packages (Section IU-D). 

Controllable devices are directly controllable by the cen- 
tral dispatch, an individual locomotive, or authorized employ- 
ees. They include power operated switches, movable bridges, 
railway. crossings at grade, hand operated switches including 
switch point detection, and highway grade crossing warning 
system monitors and controls. 

Noncontrollable devices include occupancy detection de- 
vices, intrusion detection devices, train defect detectors, track 
integrity indicators, and route integrity indicators. Field sys- 
tems interact with the other ATCS entities to provide in a 
locomotive or at the dispatch indications of the position ami 
status of a hand operated switch; the results of a train in- 
spection by wayside defect detectors including high/wide load, 
dragging equipment, hot box, hot wheel, broken wheel, loose 
wheel, wheel impact, and other defects; the status of high- 
way grade crossing warning systems; track integrity and con- 
ditions; route integrity, including derails, moveable bridges, 
spring switches, slide detectors, bridge fire detectors, high wa- 
ter detectors, wind detectors, temperature detectors, railroad 
crossing at grade, and other systems. They can accept control 
of power switches, wayside signals, and switch heaters (snow 
melters), and provide indications of their status and position. 

D. Basic Train Operations 

The management of train operations depends on complete 
knowledge of the location and status of all of the elements 
that make up the railroad, including trains, tracks, wayside 
devices, and track forces. In addition to this knowledge, train 
control requires complete specification of the steps to be taken 
to carry out any operation under all circumstances. 

Knowledge of train location is provided by the interrogation 
of transponders buried between the tracks by each train as it 
moves, and the communication of this data to the dispatcher. 

The steps involved in each operation in train movement were 
meticulously compiled as part of the ATCS design process. 
The descriptions were called "control flows" and they defined 
the "stimulus-response" behavior of the various elements of 
the ATCS that resulted in the execution of each and every op- 
eration. They were, in effect, the algorithms by which train 
operations were governed. The control flows, in turn, defined 
the information that was required for every operation, provid- 
ing the basis for the identification of the communications that 
occurred in the ATCS. 

Actual control is exercised via message transmission 
through the ATCS Communications System, in conjunction 
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with the appropriate rules, regulations, and operating proce- 
dures. 

Before a train leaves its initial terminal, a trip plan file 
containing the information defined in Table I, is downloaded 
from the dispatcher to the locomotive computer. The data in 
thai file are sufficient to allow the locomotive computer to 
calculate the braking characteristics of the train and to predict 
its speed at every point on its trip. 

After the train, route data, and the track and route charac- 
teristics file are downloaded to the locomotive computer, the 
dispatcher establishes the movement authorities to be granted 
to the train and, after they are validated by the route and block 
locking logic in the dispatch computer, they are transmitted 
to the locomotive computer. 

During the trip, on-board sensors provide the locomotive 
computer with the train speed, throttle setting, brake setting, 
acceleration rate, and locomotive health data. As the train pro- 
gresses, the locomotive computer determines the train location 
with readings from axle-mounted odometers, with checks pro- 
vided by data acquired by the transponder interrogator from 
transponders buried in the roadbed. The location data are used 
by the on-board logic to determine the appropriate limits of 
authority, speed restrictions, pacing, and other functions that 
depend on location. The locomotive computer continuously 
monitors whether the train is going too fast to slow down or 
stop at an upcoming authority limit or speed restriction and, 
if it is, warns the engineman. If the engineman does not act 
the OBC will initiate an enforcement request to the locomo- 
tive brake control system. If an authority limit is passed, it 
initiates an emergency stop. 

Violations of speed restrictions, limits of authority, and 
emergency brake applications are reported to the dispatch sys- 
tem; and the locomotive receives operational status messages 
from wayside devices and defective equipment detectors. 

E. Basic Messaging 

Information is transmitted through the ATCS communica- 
tions system in messages sent between two ATCS applications 
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or upper layer protocol entities. For example, the dispatch 
system is continuously aware of the location of every train 
since each locomotive computer transmits a location message 
to the dispatch system periodically, with corrections transmit* 
ted each time a transponder is passed; periodically when in 
communications coverage; whenever communications cover- 
age areas are entered or left; and, whenever requested to do 
so. All messages are numbered and their formats are care- 
fully defined. Message numbers have three parts: function, 
type, and specifier indicating the particular message of each 
function and type. 

The ATCS message functions are given in Table II , and the 
types of messages are shown in Table III. 

Every message is identified by a label derived from the 
message number as 

label =512* number + 64* type + specifier. 

Messages are assigned priorities indicating the timeliness 
of delivery required. Messages are further classified as vital 
or nonvital. Vital messages require special protection from 
transmission errors and delivery to the incorrect destination. 
A cyclic redundancy check is calculated on the address length, 
address, facility length, facility, and text fields of each packet 
of a vital message, and appended to each packet of the mes- 
sage. 

Messages arc made up of objects, which in turn are made 
up of fields of various data types. For example, Object Num- 
ber 2 is the ROAD/UNE/TRACK Object. It contains bit field 
data, and its bit length is 24. The fields: ROAD (12 b), LINE 
(8 b) and TRACK (4 b) indicate the owning railroad, the line 
on that railroad and the track on that line, respectively. Sim- 
ilarly, Object Number 3 is the MILEPOST Object, a 24-b 
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TABLE V 
LOCATION REPORT Message 



MESSAGE NUMBER: 
MESSAGE NAME: 
FREQ OF OCCURRENCE; 
SOURCE: 

DESTINATION: 

VITAL: 
M008: 

PRIORITY LEVEL 
SESSION: 
MESSAGE LABEL: 
MESSAGE RESPONSE: 
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DESCRIPTION: 
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I 1U correal 
I reflect t&t 



t Authority) 
P06 OBJECT NAME 

1 DESTINATION 

2 TIMB GENERATED 

8 CURRENT LOCATION 

4 CURRENT SPEED 

5 AUTHORITY START 

8 AUTHORITY END LOC 

7 TIME GENERATED 

8 CURRENT LOCATION 
0 CURRENT SPEED 

10 AUTHORITY START 

11 AUTHORITY END LOC 

TOTAL erf LENGTH: 



OBJECT TYPE NUM DATATYPE UN 



NETWORK ADDR 20 

TIME/DATE &2 

LOCATION 4 

SPEED IN MPH I 

LOCATION 4 

LOCATION 4 

TIME/DATE 23 

LOCATION 4 

SPEED IN MPH 1 

LOCATION 4 

LOCATION 4 

UIN 4» MAX 4ja 



BIT FIELD M 
BIT FIELD S3 

err field « 

BINARY SIGNED 8 
BIT FIELD 48 
BIT FIELD «8 
BITFIELD S3 
BIT FIELD 46 
BINARY SIGNED 8 
BIT FIELD 48 
BIT FIELD 48 



TABLE VI 
ATCS DIAGRAM PACKET FORMAT 



OCTET CONTENTS 



P PP A 



1 QD 1 0 

t LOGICAL CHANNEL NUMBER 

I SEND PACKET SEQUENCE NUMBER P(S> 

4 RECEIVE PACKET SEQUENCE NUMBER PQU 

8 SOURCE ADDRESS LENGTH DSST ADDRESS LENGTH 

10 1O 10 10 

6 DESTINATION ADDRESS OCTET 1 

T DESTINATION ADDRESS OCTET S 

6 DESTINATION ADDRESS O CTET 3 

B DESTINATION ADDRESS OCTET 4 

10 DESTINATION ADDRESS OCTET 6 

II SOURCE ADDRESS OCTET t 
13 SOURCE ADDRES3 OCTET 3 

13 SOURCE ADDRESS OCTET 8 

14 SOURCE ADDRESS OCTET 4 

15 SOURCE ADDRESS OCTET 6 

16 FACILITY LENGTH FORMALLY 0*S> 
FACILITY FIELD (NORMALLY NOT PRESENT) 

17-N USER DATA (128 OCTETS MAXIMUM} 



binary data object describing the position of a milepost in 5- 
ft increments. The concatenation of a ROAD/LINE/TRACK 
object and a MILEPOST object form the 48-b field of the 
LOCATION Object. 

Objects may include several subobjects. For example, Ob- 
ject Number 26, TRACK SEGMENT DATA, is a bit field 
104 b long that contains the objects shown in Table IV. 

Complete messages are defined in terms of fields defining 
their number, label, name, source, destination, vitality, mode, 
priority, session, response, and contents. A typical message, 
the LOCATION REPORT, is shown in Table V. 

Datagram packets have the format shown in Table VI. Ser* 
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TABLE VII 

ATCS DATAGRAM SERVICE SIGNAL PACKET FORMAT 



OCTET 


CONffcNTS 


1 


QD10 PPPA 


2 


LOGICAL CHANNEL GROUP 


3 


SEND PACKET SEQUENCE NUMBER PCS) 


4 


RECEIVE PACKET SEQUENCE NUMBER POD 


6 


SOURCE ADDRESS LENGTH OEST ADDRESS LENGTH 




10 10 1010 


6 


DESTINATION ADDRESS OCTET 1 


7 


DESTINATION ADDRESS OCTET 3 


8 


DESTINATION ADDRESS OCTET 3 


9 


DESTINATION ADDRESS OCTET 4 


10 


DESTINATION ADDRESS OCTET 6 


U 


SOURCE ADDRESS OCTET 1 


12 


SOURCE ADDRESS OCTET 8 


13 


SOURCE ADDRESS OCTET 3 


14 


SOURCE ADDRESS OCTET 4 


IS 


SOURCE ADDRESS OCTET 6 


16 


DATAGRAM IDENTIFICATION OCTET I 


17 


DATAGRAM IDENTIFICATION OCTET 3 


18 


CAUSE FIELD 


19 


DIAGNOSTIC FIELD 


20.3& 


NETWORK INFORMATION (16 OCTETS MAXIMUM) 



TABLE VM 
Transport Layer H£adea 



Octet 1 Bill 18 Mmmc* NoaabcT 

Bit 1 Mer* Bit (1 on bit pocket of ■ mesaagt) 

Octet 2 Bits 3-8 Part Number (Picket poriboo wilMa memft) 
Bit 1 End- to- and Acknowledge Rcquett Bit 

Octet 1 KtiU Mttuft Length (is ptckrti) 

Bit I Vital Bit (1 in ■ viu) message, vita) CRC 
UwmitUd tn bit 4 ecUU cf tin picket text) 

Octet* 4 and 6 Ut») Field 



TABLE IX 

TRANSMISSION Mouu 



MODE NAME 

0 Broadcast Mode 

1 Nor ml Mods 

2 Database Node 

9 Assurance Mod* 
4 SpeclaJ emergency 



EFFECTS 

No acknowledgement* or service eignals. 

RF acknowledgements are used and service signals 
on the statu ■ of packet* are obtained from the 
network. 

No link acknowledgement* or service 
signals, but end-to-end acknowledgements 
are used. 

Link and end-to-end acknowledgements 
are used. 

Five copies art generated and end-to-end 
acknowledgement* used. 



vice signal packets have the format shown in Table VII. The 
bits within Octet I of each packet are defined as QD10PPPA, 
where: 

Q indicates a service signal and is set to 0 on al) orig- 
inate traffic, 

D indicates that a service signal is required from the 
network back to the originator indicating whether 
the packet successfully traversed the RF link, 

PPP is the priority of the message, 

A is the ARQ disable bit. 

Octets 2, 3, and 4 are not used by ATCS. They are set to 
zero on all originate traffic and ignored on all receive traffic. 

The Transport Layer Header occupies the first four octets 
of the packet text. They are defined in Table VIII, The trans- 
mission modes are defined in table IX. 



II. Overview op the ATCS Communications System 
A. The Communications System 

ATCS Communications System users are grouped as: 

1) host applications: dispatch and MIS systems; network 
applications; 

2) locomotive applications; 

3) radio and wireline-connected wayside devices; 

4) track forces and mobiles, other than locomotives. 

The ATCS Communications System architecture is driven 
by the requirements of these users and the information flows. 
Tlie ISO seven-layer OSI model forms the basis for the ar- 
chitecture, while the mobile data radio technology used to 
provide the data path to the vehicles has had a major impact 
on the detailed implementation. 
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Fig. 2. ATCS Communication System. 



The ATCS Communications System, illustrated in Fig. 2, 
consists of three major subnetworks. These are the following. 

1) The Ground Network comprising the ground network 
nodes (comprised of front end processors, cluster controllers, 
and base communications packages) and the interconnecting 
communication lines (telephone circuits, microwave channels, 
fiber optic links, and modems). 

2) The Radio Frequency {RF) Network, comprising the 
base communications package and mobile communications 
package radios and the RF channels on which they communi- 
cate. 

3) The User Networks, which comprise the collections of 
objects and applications within each user (wayside device, 
locomotive or other vehicle and dispatch system). 

B. Network Nodes 

The front end processor (FEP) is the major entry point 
from a host computer into the ground network. It is normally 
connected to a number of cluster controllers. 

The duster controller (CC) is a routing node in the ATCS 
ground network. A CC would normally be connected to a 
number of radio base stations. 

A FEP and CC's may be combined in a single unit 
(FEP/CC) which meets the requirements of both. 

The base communications package (BCP) is a node in the 
ATCS ground network that provides an interface lo the ATCS 
Radio Network, A BCP may contain a number of base station 
radios, operating on different channel pairs. 

The mobile communications package (MCP) operates in 
locomotives, track force vehicles, and RF-connected wayside 
devices as the interface between the radio network and a loco- 
motive computer or a wayside device. It can also be used in 
an optional configuration to interface wayside devices directly 
into the ground network without using the radio channel. 



C. Network Branches 

The nodes in the ATCS Communications Network are in- 
terconnected by data communication links. The relationship 
between the OSI model and the ATCS system components is 
shown in Fig. 3. Although the two end users in this case are 
a dispatcher and a locomotive, the communications between 
other pairs of users is similar. 

Terrestrial links and on-board connections utilize common 
OSI protocols at the data link and physical layers, while an 
ATCS *' busy-bit" protocol is used to achieve channel access in 
the radio network. An X. 25 -like ATCS Datagram protocol is 
used at the network layer; and, because of the special safety 
requirements, customized protocols have been developed at 
the transport, session, and application layers. 

Flow control is exercised at two levels. Layer 2 flow control 
allows FEP's, CCs, BCP's, MCP's, and other user devices 
to stop accepting traffic for a short time when buffers are full. 
Layer 4 flow control enables end-to-end control. 

Internal ground network interfaces, based on HDLC, 
are point-to-point or polled. Point-to-point is HDLC 
balanced, linking FEP, FEP/CC and CC. It imple- 
ments FEP-FEP, CC-CC. FEP/CC-FEP/CC, FEP/CC-FEP, 
FEP-CC, CC-BCP and FEP/CC-BCP interfaces. The polled, 
interface links CC and FEP/CC to base stations and, option- 
ally, to wayside devices connected to the base station wireline. 
The polled protocol is a modified HDLC operating between 
BCP and CC. 

Each RF channel consists of a pair of UHF channels. One 
is used for base to mobile-wayside communications on a non- 
contention basis, the other for mobile/wayside to base commu- 
nications on a contention basis. Modulation is direct FSK at 
4800 kb/s. The base station operates in full duplex on the RF 
network with separate transmit and receive channels; while 
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Fig. ^. OSI layers find ATCS system components. 



the locomotive, track force and wayside devices operate on 
the complementary pair of channels in half duplex. 

III. Nodes of the ATCS Communications System 

A . The Front End Processor 

The FEP is the interface between host computers and/or 
terminals and the ground data network. The entities within 
the FEP arc as shown in Fig. 4, and are defined in ATCS 
Specification 220, Section 3.1 as: 

1) vehicle following and packet routing; 

2) ground user interface: layer 1-3 to ground based hosts 
and terminals; 

3) ground network trunks: layer 1-2 lo FEP's, CC\s, and 
FEP/CC's; 

4) network time updates; 

5) flow control 

6) buffering and queuing; 

7) configuration; 

8) failure/alarm reporting: either an attached printer or fa- 
cility to send messages or both. 

The FEP performs the following basic operations, defined 
in ATCS Specification 220, section 3.1.4: 

1) power up self-test; 

2) process traffic from ground trunks to stationary devices; 

3) process traffic from ground trunks to vehicles/Will's; 

4) process traffic from vehicles and WIU's; 

5) perform on-line health monitoring of manufacturer de- 
fined parameters. 

The FEP routes packets based on routing tables and vehicle 
location tables. It implements buffering and prioritized queu- 
ing of packets, as well as flow control techniques. Blocked 
queues are cleared by a flow control recovery procedure de- 
scribed in Section IV-F-4. The FEP contains a mechanism for 
reporting on-line failures and faults and the status of itself and 
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Fi*.4. FEP. 

the communication lines. It is connected to its host/terminals 
and to other FEP's and CC's as shown in Fig. 5. The FEP 
provides layer I, 2, and 3 interfaces to ground-based hosts 
and terminals; and layer 1 and 2 interfaces to other FEP's and 
CC's. 

The FEP attempts to route packets to their destination. If 
it is unable to do so, it generates datagram service signals tn 
inform the originator of the presence of a problem. 

B. The Cluster Controller 

The CC acts as the communications hub for a number of 
base stations. The entities within the CC are as shown in Fig. 
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Fig. 6. CC. 

6. The entities are defined in ATCS Specification 225, section 
3.1.1 as: 

1) base station management; 

2) vehicle following and packet routing; 

3) RF layer 3 protocol; 

4) ground network trunks: layer 1-2 to FEP's, CCs, 
FEP/CCs, and BCP's; 

5) network lime updates; 

6) flow control; 

7) buffering and queuing; 

8) configuration; 

9) failure/alarm reporting: either an attached printer or fa- 
cility to send messages or both. Reports CC. attached BCP, 
and communication line status. 



The CC basic operations are defined in ATCS Specification 
225, section 3.1.4 as: 

1) power up self-test; 

2) process traffic from trunks to stationary devices; 

3) process traffic from trunks to vehicles/WllTs; 

4) process traffic from vchiclcs/WOTs; 

5) on-line health monitoring of manufacturer defined pa- 
rameters. 

Like the FEP, the CC routes packets based on routing ta- 
bles and vehicle location tables, which must be maintained as 
the situation changes. It implements buffering and prioritized 
queuing of packets, as well as flow control techniques. The CC 
also contains a mechanism for reporting on-line failures and 
faults and the status of itself and the communication lines. The 
CC is connected to FEP's and CCs, and to BCP's, as shown 
in Fig. 5. The CC provides the RF Layer 3 protocol, and 
implements the Layer 1 and 2 interfaces to FEP's, FEP/CCs, 
CCs and BCP's. Connections to BCP's are normally operated 
with the ATCS/HDLC polled protocol, but may be optionally 
star-connected and use the HDLC Balanced protocol. The CC 
is also responsible for base station management in terms of 
directing tests of base stations and in exchanging traffic with 
them. 

C, The Base Communications Package 

The BCP is the interface between the ground network and 
the radio network. The entities within the BCP are as shown 
in Fig. 7. The entities are defined in ATCS Specification 230, 
section 3.1.1 as: 

1) base station radio; 

2) wireline interface; 

3) local routing; 

4) radio interface; 

5) packet buffering and queuing; 

6) self-test; 

7) signal quality 

8) receive channel health monitoring; 

9) bufferless option: (this option may be implemented where 
the BCP and CC are manufactured by the same supplier, and 
the railroad does not require compatibility with other suppli- 
ers' CCs or BCP's). 

The BCP contains one or more data radios and is connected 
to its controlling CC via the ATCS/HDLC Polled or HDLC 
Balanced Layer 2 protocols. The BCP implements the ATCS 
Radio Link data link layer protocol to communicate via UHF 
radio channels with locomotives and trade forces within its 
coverage area. 

Emergency traffic received on in-bound channels is relayed 
immediately to all out-bound channels. 

The BCP is capable of performing a self-test upon com- 
mand and reporting the results of the test. The test includes 
software integrity and radio status. 

The BCP monitors all received radio signals and continu- 
ously reports the signal levels to the controlling CC. Alarm 
messages arc sent when the BCP detects carrier with no data 
for greater than 1 .5 s and when a MCP is detected transmitting 
for longer than 10 s. 
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Fig. 7. BCP. 

D. The Mobile Communications Package 

The MCP is the interface between the radio network and 
locomotive computers, intelligent terminals, and wayside de- 
vices. The entities within the MCP are as shown in Fig. 8. 
The entities are defined in ATCS Specification 210, section 
3.1, as: 

1) frequency controller; 

2) radio network layer 3 protocol entity; 

3) local routing logic; 

4) layer 2 (HDLC Balanced) protocol entity; 

5) layer 2 (RF network) protocol entity; 

6) layer I (RS 422) interface; 

7) radio; 

8) packet buffering and queuing; 

9) self-test; 

10) in coverage contact timer. 

The MCP contains a frequency controller, local routing 
logic, and the means to buffer packets to and from the ra- 
dio, the frequency controller, and its "client" interface. The 
MCP is connected to the radio network via a data radio. It im- 
plements the ATCS radio network layer 3 datagram protocol 
and the radio link layer 2 protocol. The MCP is connected 
to its "clients" via an HDLC/RS 422 interface. The MCP 
operates in a number of modes: power up, in which a self- 
test is automatically performed; normal operation, in which 
traffic is processed routinely; impaired operation, in which 
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Fig. 8. MCP. 

the MCP rejects all traffic; and disabled operation, in which 
the MCP refrains from transmitting; flow control, in which 
the MCP clears its buffers; and out-of-coverage, in which the 
MCP interacts directly with wayside devices. 

IV. Protocols in the ATCS Communications System 
A . Upper Layers 

J) The Application and Presentation Layers: The ATCS 
application layer protocol provides the bridge between the ap- 
plications program and the ATCS data communications sys- 
tem. It provides the mechanism that allows an application to 
open and close communications sessions, to be informed of 
the state of those sessions and to send and receive data on 
those sessions. Unique features of the ATCS application layer 
include the special handling of emergency messages. 

2) Session Layer: The ATCS session layer protocol pro- 
vides the services necessary to ensure that only data in ap- 
propriate formats are provided to applications. In the ATCS 
system it is also responsible for assigning priority, class of 
service to send traffic, for Ragging traffic as vital (life threat- 
ening) or nonvital, and for ensuring that vital data are not 
carried in a nonvital mode. 

The session layer provides the mechanism that controls the 
association and disassociatton of applications that must co- 
operate to perform their functions. There are three. types of 
sessions in the ATCS network. They are: the general pur- 
pose session (mandatory for all ATCS communication system 
users), the master session (mandatory for all users who control 
other users, and the slave session (mandatory for all users who 
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arc controlled by other users). Sessions are controlled (opened 
and closed) by a defined set of signals and control messages. 

3) Transport Layer: The ATCS transport layer provides 
the services of message segmenting and reassembly, dupli- 
cate elimination, vital message integrity checking, end-to-end 
acknowledgment, and handling of priority traffic. The trans- 
port layer depends upon certain fields in the message packet 
headers to determine the way in which it will handle mes- 
sages. Procedures are defined to describe the way in which re- 
ceived service signals and message packets are treated. Layer 4 
may originate traffic, and interprets the following transmission 
modes: broadcast, normal, data base, assurance, and special 
emergency broadcast. The transport layer is capable of end- 
to-end acknowledgment as well and selective nonacknowledg- 
meni, receiver abort, receiver reject, transmitter abort, and 
receiver delay request (which causes message queuing in var- 
ious nodes). Layer 4 maintains timers that monitor end-to-end 
acknowledgments. FinaJlyi the transport layer imposes a re- 
dundancy check code (32-b CRC) on vital messages. 

B. Layer 3: Datagram Packets 

1) Ground Network Protocol: As introduced in Section 
l-E, information is transmitted through the ATCS Commu- 
nications System in packets in a datagram mode. That is, 
information is transmitted in independent packets, or data- 
grams, rather than in a virtual circuit mode. The information 
is communicated as either messages or service signals, and 
they have different packet formats. Service signals are used 
for the communication of information relevant to the com- 
munication system, while message packets carry operational 
information. 

2) Radio Network: The layer 3 radio network protocol is 
responsible for controlling the transfer of packets across the 
radio network. Layer 3 entities maintain a prioritized queue 
through which packets are passed to layer 2 entities for trans- 
mission. 

Traffic is controlled on the RF link by channel group. Traffic 
on odd numbered channels is sent without acknowledgment 
and traffic on even numbered channels is sent with the ex- 
pectation of acknowledgment. In exchanges of traffic on even 
numbered channel groups between the ground network and 
RF users, a maximum of one unacknowledged packet may be 
outstanding. Layer 3 procedures are defined for the transfer 
of unacknowledged traffic and the exchange of acknowledged 
traffic between the ground network and RF users, and between 
RF users. Procedures are defined for generation of acknowl- 
edgments, and the operation of the RF network in a polled 
mode. 

C. Lower Layers in the Ground Network 

Communications between ground hast and terminal users 
and FEP's, CC's, and FEP/CC's are governed by the LAPB 
data link protocol, as defined by CCITT Recommendation 
X.25 Section 2. 

Communications between FEP's, FEP/CC's and CC's, and 
between OBC's and the MCP are governed at the data link 
layer by the HDLC Balanced protocol, class BAC IA, 2, 4 



as defined in ISO specification 6256. On-board link layer ad- 
dresses are defined, for use in the XID identification process. 
Frame lengths and timer limits are defined; up to seven out- 
standing information frames are permitted. 

Communications between CC's (or FEP/CC's) and the BCP 
is an adaptation of HDLC called the ATCS/HDLC Polled Pro- 
tocol. The CC (or FEP/CC) implements the master side of the 
protocol while one or more BCP's may be attached to the line 
to implement the slave side of the protocol. 

The protocol allows for information, self-test command, 
poll, and reset command frames to be sent from the master to 
the slave; and for information, self-test performance, self-test 
request, receive ready (RR), and receive not ready (RNR) 
frames to be sent from the slave to the master. 

The default physical layer interface for the ATCS ground 
network is EIA RS 232C, although RS 422 may be used op- 
tionally. The default data rate for these data links is 9.6 kb/s, 
with 4.8, 19.2 and 56 kb/s as options. 

D. The Radio Data Link Layer 

Data are transmitted on the RF link in frames and blocks. 
The radio data link layer protocol is used between way- 
side/mobile users and base stations in coverage areas and be- 
tween wayside and mobile users in "dark" territory. 

Packets received from the radio network layer 3 protocol 
are segmented into frames containing a 40-b frame synchro- 
nization sequence (07092A446F hex), the destination address, 
a pad count indicating the number of O's added to the infor- 
mation field, a length field indicating the number of blocks 
required to hold the frame, a header CRC field, an informa- 
tion field which can hold a datagram packet, a pad field, and 
an information CRC. Both CRC's are calculated according to 
the polynomial G(x) or 16 +jc 12 +x s + 1. 

The frame is segmented into blocks of 60 b with the last 
block padded with zeros to make its length exactly 60 b. Each 
block is FEC encoded for transmission using a Reed- Solomon 
(16,12) code, resulting in a block length of 80 b. Five "busy 
bits'* are added to the encoded block before transmission. The 
busy bits are inserted in the encoded bits, i.e., between bits 
15-16. 30-31, 45-46, 60-61, and 75-76. The busy bits reflect 
the state of the inbound channel at transmission time. When it 
is transmitting, the BCP sets the busy bits to 0 if the receive 
(inbound) channel is idle, and to I if it is receiving inbound 
radio traffic. The MCP always transmits with the busy bib set 
to I. 

An MCP accesses the channel by monitoring the state of 
the channel. If the channel is free (no base station carrier) 
the channel is accessed. If the MCP receives sync patterns, 
a random delay is introduced, and the state is rcmonitorcd. 
If data are received and the last three busy bits are set to 0, 
the channel is accessed; otherwise the channel is remonitored 
after a random delay. 

When a block is received the busy bits arc removed and 
an error correction algorithm applied. The first 40 b of the 
first decoded block are checked for a valid header CRC. If 
it is correct, subsequent blocks are decoded as specified by 
the length field; and the received data are passed to the frame 
decoder. If the packet CRC is bad, the packet is discarded. 
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E. The Radio Signals 

The ATCS radio network consists of pairs of UHF channels. 
The channels are in the 896/935 MHz band. 

The data radios operate on a pair of channels (BCP in full 
duplex, MCP in half-duplex) at 4800 bis. The method of 
modulation is baseband filtered frequency shift keying. The 
Gaussian filter has a time bandwidth product of 0.5, and the 
frequency deviation is H — 1.7 kHz. 

F. Special Features 

1) Maintenance of Vehicle Following Tables: Each rout- 
ing node (FEP, FEP/CC or CC) in the network must maintain 
tables containing a list of other routing nodes and the paths to 
those nodes; a list of stationary users for whom the node is the 
controlling node and how to pass packets to those users; and 
a. vehicle following table: a list of vehicles and the identity of 
their controlling node. For vehicles controlled by the node, the 
table contains the information necessary to get packets to that 
vehicle (which base to use). The routing tables are configured 
from the ground network, the vehicle following tables are cre- 
ated and maintained dynamically. The latter are automatically 
purged every 10 min of all unused entries. 

When a node receives a message for a vehicle that is un- 
known, it sends a search message to all other nodes. When 
this message is received by the node that controls the unknown 
vehicle, it transmits a notification message to all nodes. The 
same thing happens when a node first receives a message from 
a vehicle over which it did not previously have control. 

2) Network Time Updates: The dispatch safety system 
maintains a master clock and disseminates the time to all ele- 
ments under its control by broadcasting time update messages 
at least once every hour. Time update messages are also trans- 
mitted in response to time query messages, which may be used 
a means for elements to check the system integrity. Medium 
and low priority traffic through ground network nodes is sus- 
pended (and queued) for 5 s whenever a network time update 
warning message is received. This ensures that network time 
update messages will be transmitted without delay through the 
network. 

3) Priority Traffic and Prioritized Queues: ATCS traffic 
is divided into eight priority levels. All traffic is buffered and 
queued in prioritized queues. Top priority is given to emer- 
gency, time critical, and operational traffic. Normal traffic 
and long messages are given lower priority but have assured 
access to the communications network; history data has the 
lowest priority. 

4) Flow Control Recovery: When a node has been in flow 
control at layer 2 for 5 s, it begins discarding traffic from its 
queues, lowest priority first, with the exception of emergency 
traffic. If this process does not result in the termination of 
flow control within 10 s, the node declares a major failure 
and discards all traffic. If the node remains in flow control 
after this, a power-up reset is attempted or the node switches 
to a standby processor, if one is available. 

V. Summary 

The ATCS, and particularly the ATCS Communications 
System, represents a major application of modem commu- 



nications systems design principles. It is based on the open 
system concept and provides manufacturers with the maximum 
amount of freedom to exercise their ingenuity in realizing any 
one of the entities, while assuring them (and the railroads) 
that entities manufactured to ATCS Specifications will have a 
market, and the system incorporating them will perform as 
required with improved efficiency, safety, and economics. 
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Analytical Model for ATCS 
Inbound RF Channel Throughput 



Hamid R. Sharif 

Electronics Engineering Technology 
University of Nebraska-Lincoln 
Omaha, NE 

Abstract - An analytical model has been devel- 
oped to analyze the throughput of the Advanced 
Train Control System (ATCS) inbound RF 
channel for a finite number of mobiles. The 
inbound channel access protocol is a special 
version of Corner Sense Multiple Access 
(CSMA) protocol The model is intended to pro- 
vide an analytical method of predicting the 
effect of packet collisions and retries on inbound 
RF channel throughput. 



Edward L. Furman 
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The access method for the inbound channel is a 
CSMA-type protocol. This adds an overhead of 
retries for the collided packets in the channel 
load. The basic measure for the efficiency of an 
RF protocol (and in general for CSMA-type 
protocols) is throughput, i.e., the average fraction 
of time that the channel is used for useful data 
communication. Three factors accounting for the 
throughput degradation are propagation delay, 
mobile's idle period, and packet collision. 



/. Introduction 

The Advanced Train Control System (ATCS) 
[1-3] is a concept developed by North American 
Railroads working through the Association of 
American Railroads and Railway Association of 
Canada. ATCS is intended to provide for safer 
railroad operation by linking a central dispatching 
and safety computer with computers on locomo- 
tives and controlling wayside switches. The 
locomotive computer is equipped to stop the 
locomotive before a stored movement authority 
can be exceeded. The central safety computer 
communicates with wayside and locomotive com- 
puters over an RF data link. 

The ATCS RF link operates on pairs of RF 
channels in the 900 MHz band. One channel is 
used for inbound (from the locomotive to the 
base) transmission. The other channel is used for 
outbound (from the base to the locomotive) trans- 
mission. The baud rate is 4800 bits per second. 



A number of studies have been published on the 
throughput analysis of CSMA-type protocols [4]. 
However, most of them have been based on the 
assumption of infinite nodes. This type of popu- 
lalion provides collective channel traffic which 
forms Poisson process with a finite rate. 

In the ATCS system, a finite number of loco- 
motives may operate in the coverage of a base 
station. For this reason, it is more appropriate to 
analyze the throughput of the inbound RF channel 
analytically by assuming a finite population of 
mobiles. The model developed for analyzing the 
throughput of an ATCS inbound RF channel for 
a finite number of mobiles is the topic of this 
paper. 



//. RF Channel Access Protocol 

With the ATCS data radio network, messages to 
be sent over the radio channel are separated into 
packets. Each packet is addressed with source 
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and destination information before transmission. 
Successful delivery of a packet is verified by 
receipt of an acknowledgment from the destina- 
tion. Depending upon the mode selected for 
transmission, acknowledgments will be sent either 
for an individual packet (mode 1) or for a group 
of packets (mode 2). 

A mobile radio system is subject to noise and 
fading conditions which can result in data errors. 
Forward Error Correction (FEC) is used over the 
radio link to recover from errors during trans- 
mission. The FEC code used is a Reed-Solomon 
which adds bits for error detection and correction 
to every block of data. Messages to be 
transmitted are separated into 60-bit blocks. Each 
60-bit block becomes 80 bits long when the FEC 
bits are added. This 80-bit block of data encoded 
with FEC provides the basic structure for all 
ATCS RF data traffic. 

In its most simple form, the RF link consists of 
a single base station communicating with a 
number of mobiles. In actual operation there may 
be more than one base station involved in the link 
to a mobile. The base station transmits on one RF 
frequency and receives on a different RF fre- 
quency. The base station is full-duplex equipment 
while the mobiles and wayside equipment are 
half-duplex. The inbound traffic received by a 
base station is characterized by random trans- 
missions from a number of locomotives and other 
mobiles of the RF link. Mobiles can't hear each 
other but they all hear the base. To minimize the 
inbound collisions, the base station is used to 
inform the mobiles when inbound traffic can be 
sent. 

In order to provide a method for managing 
inbound channel access, additional bits called 
"busy bits" are added to the 80-bit data block 
described above. For every 15 bits, an extra bit 
is added, making a total block of 85 bits. When 
a mobile transmits, the busy bits are all set. At 
the base station, the busy bits in the outbound 
data stream reflect the status of the inbound 
channel. If the bit is set, the channel is busy. If 
the bit is reset, then the channel is idle. 



When a base station is transmitting data out- 
bound, it will insert busy bits in the data stream 
upon receipt of inbound traffic. These busy bits 
are monitored by the other mobiles wanting to 
use the channel. When a mobile checks the chan- 
nel and finds that some or all of the last 3 busy 
bits were set, it will wait a random time from 10 
to 2000 ms before checking the channel again. If 
the mobile finds the last 3 bits set to idle when it 
checks the channel, it will access the channel. If 
a synchronous pattern is detected, the mobile will 
wait a random period between 10 and 800 ms and 
then check the channel again. If fewer than three 
busy bits have been received since the synchron- 
ous pattern, the mobile will wait a random period 
between 10 and 50 ms and check the channel 
again. 



fl7. Model Description 

An analytical model described below has been 
developed for the throughput analysis of the RF 
inbound channel with a finite number of mobiles. 
This model is based on the assumption that each 
mobile has independent periods of time in which 
the mobile has no packets to send. By superim- 
posing these idle periods over all mobiles, the 
system's idle period is exponentially or geo- 
metrically distributed. This makes the system 
more manageable by using the memoryless prop- 
erty [5, p. 66]. This assumption was not made 
for the infinite population case due to the 
Palm-Khinchine theorem [6]. 



Packet lengths are assumed to be constant (251- 
byte data) and equal to X, and packet transmis- 
sion time is XIR (R baud rate); for convenience 
XIR was denoted as P. The vulnerability window 
which determines how many inbound collisions 
will occur on the channel, is denoted by n a n . "a* 
is determined based on tpIP where tp is: 
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where 



W 



Mobile to base station propagation 
delay 

Base station bit synchronization 
Base station busy bit insertion 
Base station to mobile propagation 
delay 

Mobile serial communication delay 
Mobile communication delay (PTT) 



The model developed is capable of providing a 
throughput analysis of a finite number of mobiles 
and a single base station in line-of-sight of all 
mobiles. The model also assumes acknowledge- 
ment packets are always correctly received and 
the base station is configured to access the out- 
bound channel continuously. 

A Relationship between 5, normalized throughput 
with respect to P, and G, the normalized total 
offered load including the retries can be obtained 
by considering time as consisting of cycles of 
alternating busy and idle periods. A cycle ends 



with an idle period during which no mobile is 
attempting to transmit. The cycle is initiated by 
arrival of a packet to some mobile following an 
idle period. A cycle containing multiple trans- 
missions is illustrated in Figure I. 

In Figure 1, the packet initiating the cycle is 
denoted by packet 0. In steady-state, all cycles 
are statically similar; thus throughput can be 
determined as the ratio of the average amount of 
time devoted to successful transmission during a 
cycle, to the average total length of the cycle. 
Denoting the average duration of the time devot- 
ed to successful transmission as U t the average 
length of the idle time . period as '. W W 
average length of the busy time period as B t S 
can be expressed as: 

s- -X. to 

Where X denotes the expectation of the random 
variable X. 



TIME 




Figure 1. Inbound RF Channel State 
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Upon the arrival of a packet, the network enters 
the "busy" time period. The busy period termi- 
nates at the end of a transmission period in which 
no packets have arrived. 

A channel busy period is divided into a number 
of successive sub-busy periods, each consisting of 
a transmission delay followed by transmission 
time. The transmission delay is the time during 
which the channel is idle but some packets are 
awaiting transmission. If a transmission is suc- 
cessful, its duration is 1 + a. If a transmission is 
unsuccessful, its duration is I + a + Y, where Y 
is the transmission start time of the last colliding 
packet. Note that the jth sub-period, 72:2, is 
generated by the packets which arrive during I + 
Y in the (M) rt sub-period, whereas the first 
sub-period is always generated by one packet. Let 
Bn be the mean duration of the busy period 
initiated by n packets, and let Un be the mean 
number of successful transmissions in the same 
busy period. Also, if it is assumed that the time 
until a packet arrives at each of the empty 
mobiles is independent and exponentially 
distributed with mean I/g. Then, 

B - Bl; V - Ul. 



since 



gM 



then (I) for M mobiles gives 
Ul 



Bl^~ 
gM 



(2) 



time at the start of this sub-period, let N(x) be the 
number of packets present in the system at time 
jr. The distribution of the transmission delay 
denoted by R on the condition that N(0) = n is 
first considered. Each of n busy mobiles sched- 
ules his transmission after time x with a proba- 
bility of PR. 

Consider the event 

[R > x, N(x) 

- n + m | N(0) - n) 

where PR - e~ px . 



where m is the number of arrivals during R. For 
this event to occur, each of the M-n-m mobiles 
does not have an arrival before x with a probab- 
ility of PG. For each of m mobiles, the time until 
arrival plus start of transmission is less than x, 
with a probability of 

Jo 

p-g 

where PG-e' 3 *> 



Thus, 

Prob[R>x, Nix) - mjn|tf(0) - n] (4) 



Now if a system of linear equations is derived for 
[Bn; n - 1, 2, . . . , M) 
and 

[Un; n - 1, 2, . . . , M) 
then S is obtained. 

Next, a sub-busy period that begins with n 
packets is considered. Taking the origin of the 



_ e -pxn |M-nj e -gx{M-n-m) 

X * 0 jn - 0, 1, 2, . 



g(e-g*-e-'*) 



P-g 
,M-n. 



Adding (4) over all m 

Prob [R>x\ N(O)-n) & 



- e" pxn 



( pe'^-ge-v j 



p-sr 
x * 0 
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so that the mean transmission delay conditioned 
onN(0)=nisgivenby 



E[R in) ) - E[R\N(0)-n) « 
n - 1, 2, . . . , M 



The behavior of AM mobiles in the transmission 
period following the transmission delay is next 
considered, so that R=x and N(x) = n + m. 
During the first a time units, each mobile 
behaves independently. Each of n + m - 1 
(which has packets to transmit) mobiles either 
does not start transmission before a, with a 
probability of PA, or starts transmission before y 
with a probability of PY. There are three cases of 
behavior for each of the M-n-m mobiles who 
were empty at the end of R: 



Therefore 

Pxob[Y$y\R-x, Nix) -n + /n, W(0) -n] (7) 

[ pd-e-gr+e-g*) - a(l-e^e' pl ) 
osysa 

is the probability of a successful transmission. 
Unconditioning (7) on N(R) and R, using (4) and 
(5) successively, gives: 

f(y;n)k?rob [Y*y\NiO) -n] 




n " 1 1 2 i M 



i) no arrival during a with 

probability e . . and simitar unconditioning for the probability of 

ij) arrival before a, but transmission & successful tranmission yields 

after a, with probability , w-n 

(p-g) 2, 
PA - e" pa 
py - l-e" py 

Note y that is the probability of success in the 
sub-period begun with n packets. The mean of Y 
in the similar sub-period is given by 

iii) arrival and transmission before y, 

„i,h probability ^ 4 E[y|W(0)-n] 

" 1 n-1,2, 
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Finally, the condition has K accumulated packets 
at the end of the transmission period is consi- 
dered. If the duration of the transmission period 
is 1 + a + y t those packets which arrive during 
1 + y are buffered. Therefore, the probability of 
having K packets in the transmission period of 
duration I + a + y is given by &(1 + y) t 
where: 

9* {y) * (k) (l-e-^jV^^ 

JC- 1, 2, . • . , M 

By similar unconditioning, the probability that 
the next sub-period begins with k packets is 
written as: 

p r* - ■%■(!") f('0 

+ /Vjd+y) dyf(y;n) 

where fly\n) is given by (8). 

Now a set of equation for Bn and Un can be 

concluded: 

H 

B a -B[R ia) ) + 1 ♦ a ♦ £[y (n) ] * £ B^ nJt 



and 



- 1, 2, 



1,2 M 



Thus, the throughput can be computed from 
substitution of Bl and VI into (2). 

/V. Jtowto 

The prediction of the inbound RF channel 
throughput by the developed model for a number 
of mobiles is plotted. Figure 2 illustrates the 
throughput versus the offered load (normal load 
plus the retried overhead) for different numbers 
of mobiles (M). The throughput prediction plot 
shows that as the number of mobiles increases, 
the maximum throughput decreases. However, 
for a small number of mobiles (M £ 10), the 
throughput decrease is more noticeable than for 
a large number of mobiles. The throughput varia- 
tion for large numbers of mobiles is almost null. 

The results of actual testing performed with four 
mobiles at the Automated Monitoring and Control 
International, Inc. (AMCI) laboratory is plotted 
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Figure 2. Model Throughput Predictions for Inbound RF Channel 
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in Figure 3. By comparing the results of the labo- 
ratory testing to the results of the analytical 
model, one can observe that the model prediction 
throughput is higher than the laboratory data for 
the smaller load. However, as the load increases, 
the model prediction is much closer to the 
laboratory data. 



V. Model Verification 

Several test configurations with different numbers 
of mobiles were set up at the AMCI laboratory to 
evaluate the accuracy of the predictions of the 
described model. The laboratory test configur- 
ation consisted of locomotive computers known 
as On Board Terminals (OBT), Mobile Com- 
munication Packages (MCP) where the connec- 
tions between the OBT and RF channels were set 
up, a test fixture for the RF channel emulation, 
and the Base Communication Package (BCP) 
which provided base station functions. 

Four mobiles were configured to communicate 
with a base station through a test fixture in 



AMCI laboratory. Each mobile was set up to 
transmit packets randomly in a time frame in 
which the upper and lower random delays were 
defined. Also, different message sizes (different 
packet numbers in a message) and different ses- 
sions were used to control the offered load to the 
channel. 

As mentioned, Figure 3 shows the results of 
laboratory testing collected data and the predicted 
throughput from the analytical model for the 
same environmental variable values. As can be 
observed, the throughput predicted differs by 
about 12% from collected data in the laboratory 
testing. It is believed that the different sources 
such as precision in data collection in Oie 
laboratory, and test fixture emulation of the RF 
channel are the contributing factors to the 
difference. 

Summary 

An analytical model for throughput analysis of 
the ATCS inbound RF channel is presented for a 
finite number of mobiles. The model is based on 
a special case of the CSMA protocol. The accu- 



a* 029 




Figure 3. Throughput of Inbound RF Channel (« = -029)RF Channel 
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racy of the model's predicted throughput data 
was verified at the AMCI laboratory where 
similar results were obtained through actual 
testing. Thus, an accurate prediction of the 
inbound RF channel throughput for different 
offered loads in the ATCS environment can be 
provided. 



A best-case assumption for this model presumes: 

i) a base station in line of 
sight of all mobiles, 

ii) no overlapping radio 
coverage, and 

iii) acknowledgment packets are 
always correctly received. 

The model shows that maximum throughput 
values are not always dependent on the number 
of mobiles as long as the number of mobiles is 
reasonably large. It also demonstrates that the 
throughput of large numbers of mobiles quickly 
degrades with congested traffic (large load), 
while the throughput of a network containing a 
small number of mobiles does not degrade as 
fast. 

The ATCS RF inbound throughput analysis based 
on the model described here shows sufficient 
capacity to address the current and future needs 
of ATCS data communication traffic. The chan- 
nel access mechanism has been found to be well 
suited for a wide range of numbers of mobiles 
(small or large) that support high throughput. The 
throughput is mainly a function of the collision 
window *a° which is reasonably small in the 



ATCS' Held. Indeed, the retransmission load due 
to packet collisions does not greatly reduce the 
channel capacity. This is due to the implemen- 
tation of the "busy bits" and the full-duplex 
operation of the base stations. 
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